Stanford University proposes OpenFlow protocol in 2008, the protocol adopts a forwarding/control separate architecture, and an external control plane entity adopts OpenFlow protocol to control forwarding plane equipment to implement various forwarding logics. The forwarding plane equipment mainly functions in executing controlled forwarding according to a flow table transmitted by an OpenFlow network controller, and its behaviour is standardized to: receive a message, extract an L2/L3/L4 related field value of its header, search the flow table by taking the L2/L3/L4 related field value as a keyword, translate a field of the message according to an instruction set in a table entry content after a table entry is matched and forward the message to a certain logical or physical port after translation. The protocol is further evolved into a basis for a Software Defined Network (SDN) technology, that is, various complex network applications may be implemented by adopting software programming on a control plane without any change in the forwarding plane equipment. The control plane adopts a universal server and a universal operating system, and the network applications may be implemented by virtue of a universal software programming tool as well as a script programming language such as Python (an object-oriented interpreted computer programming design language), which makes the supporting of a new network protocol become very simple and greatly shortens a development cycle of a new technology.
A basic OpenFlow network includes two major control entities, i.e. a network controller and a switch. A centralized network controller responsible for management and control over all the switches in the whole network domain is usually deployed in the network. However, a single centralized network controller may become a bottleneck of network scale-up, for example, a time delay of flow establishment with the switch farer away from the network controller is increased, switching path request processing throughput of a single network controller is limited, and an end-to-end path is poor in bandwidth controllability. Therefore, the academic circle proposes distributed network controller solutions, such as hyperflow management and Online Information Exchange (ONIX), and in these solutions, multiple network controllers for managing and controlling an SDN together are usually deployed on the network.
In the technical solution disclosed in an American patent application with the publication number of US20110261722: routing path information is placed in a header of a first data message of a flow, and a switch on a path establishes a forwarding flow table according to the routing path information in the header of the message when performing message forwarding. For such a large-scale network, multiple switches and multiple network controllers are usually involved in connection selection and maintenance and path calculation and transmission between the switches and the network controllers, which greatly increases network maintenance cost.
Thus it can be seen that flow table transmission of multiple network controllers and multiple switches is often involved in a path establishment process in an existing distributed network controller solution for an SDN, and a complex interaction process increases complexity in service maintenance, goes against state unification of a management plane and a forwarding plane and greatly increases network maintenance cost.